home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc887 < prev    next >
Text File  |  1995-07-25  |  37KB  |  914 lines
  1. Network Working Group                                         M. Accetta
  2. Request for Comments: 887                     Carnegie-Mellon University
  3.                                                            December 1983
  4.  
  5.                        RESOURCE LOCATION PROTOCOL
  6.  
  7.  
  8. This note describes a resource location protocol for use in the ARPA
  9. Internet.  It is most useful on networks employing technologies which
  10. support some method of broadcast addressing, however it may also be used
  11. on other types of networks.  For maximum benefit, all hosts which
  12. provide significant resources or services to other hosts on the Internet
  13. should implement this protocol.  Hosts failing to implement the Resource
  14. Location Protocol risk being ignored by other hosts which are attempting
  15. to locate resources on the Internet.  This RFC specifies a draft
  16. standard for the ARPA Internet community.
  17.  
  18. The Resource Location Protocol (RLP) utilizes the User Datagram Protocol
  19. (UDP) [1] which in turn calls on the Internet Protocol (IP) [3] to
  20. deliver its datagrams.  See Appendix A and [6] for the appropriate port
  21. and protocol number assignments.
  22.  
  23. Unless otherwise indicated, all numeric quantities in this document are
  24. decimal numbers.
  25.  
  26. 1. Introduction
  27.  
  28. From time to time, Internet hosts are faced with the problem of
  29. determining where on the Internet some particular network service or
  30. resource is being provided.  For example, this situation will arise when
  31. a host needs to send a packet destined for some external network to a
  32. gateway on its directly connected network and does not know of any
  33. gateways.  In another case, a host may need to translate a domain name
  34. to an Internet address and not know of any name servers which it can ask
  35. to perform the translation.  In these situations a host may use the
  36. Resource Location Protocol to determine this information.
  37.  
  38. In almost all cases the resource location problem is simply a matter of
  39. finding the IP address of some one (usually any) host, either on the
  40. directly connected network or elsewhere on the Internet, which
  41. understands a given protocol.  Most frequently, the querying host itself
  42. understands the protocol in question.  Typically (as in the case of
  43. locating a name server), the querying host subsequently intends to
  44. employ that protocol to communicate with the located host once its
  45. address is known (e.g. to request name to address translations).  Less
  46. frequently, the querying host itself does not necessarily understand the
  47. protocol in question.  Instead (as in the case of locating a gateway),
  48. it is simply attempting to find some other host which does (e.g. to
  49. determine an appropriate place to forward a packet which cannot be
  50. delivered locally).
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Accetta                                                         [Page 1]
  58.  
  59. RFC 887                                                    December 1983
  60. Resource Location Protocol
  61.  
  62. 2. Resource Naming
  63.  
  64. Although the resource location problem can, in most cases, be reduced to
  65. the problem of finding a host which implements a given Internet based
  66. protocol, locating only a particular lowest level Internet protocol
  67. (i.e. one assigned a protocol number for transport using IP) is not
  68. completely sufficient.  Many significant network services and resources
  69. are provided through higher level protocols which merely utilize the
  70. various lower level protocols for their own transport purposes (e.g. the
  71. FTP protocol [2] employs the TCP protocol [4] for its lower level
  72. transport).  Conceptually, this protocol nesting may even be carried out
  73. to arbitrary levels.
  74.  
  75. Consequently, the Resource Location Protocol names a resource by the
  76. protocol number assigned to its lowest level Internet transport protocol
  77. and by a variable length protocol/resource specific identifier.  For
  78. example, the UDP based Echo Protocol can be named by its assigned
  79. protocol number (17) and its assigned 16-bit "well-known" port number
  80. (7).  Alternatively, the Internet Control Message Protocol [5] (lacking
  81. any higher level client protocols) would be named simply by its assigned
  82. protocol number (1) and an empty protocol specific identifier.  On the
  83. other hand, some as yet undefined resource protocol (provided via say
  84. TCP), might be named by the assigned protocol number (6), its 16-bit
  85. "well-known" TCP port number, and then some additional fixed or variable
  86. length identifier specific to that TCP port.
  87.  
  88. In general, the components of the protocol/resource specific identifier
  89. are defined to be the "natural" quantities used to successively
  90. de-multiplex the protocol at each next highest protocol level.  See
  91. section 5 for some sample assignments.
  92.  
  93. 3. Protocol Summary
  94.  
  95. The Resource Location Protocol is a simple request/reply procedure.  The
  96. querying host constructs a list of resources which it would like to
  97. locate and sends a request message on the network.  A request message
  98. may be sent either to a particular IP address and host or, on networks
  99. which provide broadcast address capability, to the IP address which
  100. refers to all hosts on that network (see [7]).  For example, a host
  101. attempting to locate a domain name server might construct a request
  102. containing the resource name [17, 53] (referring to the Domain Name
  103. Server protocol provided at "well-known" UDP port 53) and then broadcast
  104. that request on its local network.
  105.  
  106. Each receiving host examines the list of resources named in the request
  107. packet, determines which of the resources it provides, and returns a
  108. reply message to the querying host in confirmation.  The receiving host
  109. determines whether or not it provides a resource by successive
  110. decomposition of the resource name until either the name is exhausted or
  111. it encounters a component which is not supported.  In the previous
  112.  
  113.  
  114. Accetta                                                         [Page 2]
  115.  
  116. RFC 887                                                    December 1983
  117. Resource Location Protocol
  118.  
  119. example, each host on the network receiving the broadcast request would
  120. examine the resource name by first consulting its tables to determine if
  121. it provided UDP service.  If this was successful, it would then examine
  122. the UDP port component of the name and consult its UDP table to
  123. determine if it provided service on UDP port 53.  At this point the name
  124. would be exhausted and if both checks were successful the host would
  125. return a reply message to the querying host indicating support for that
  126. resource.
  127.  
  128.  
  129.  
  130. 3.1. Request Messages
  131.  
  132. RLP provides two basic types of request messages which may be
  133. transmitted by a querying host.  The first type requires any host
  134. receiving the request message to return a reply message only if it
  135. provides at least one of the resources named in the request list.  The
  136. second type requires any host receiving the message to always return a
  137. reply message even if it provides none of the resources named in the
  138. request list.
  139.  
  140. These two types of request messages are:
  141.  
  142. <Who-Provides?>
  143.     This type requires any host receiving the message to return an
  144.     appropriate reply message which names all of the resources from the
  145.     request list which it provides.  If the receiving host provides none
  146.     of the named resources, no reply may be returned.
  147.  
  148. <Do-You-Provide?>
  149.     This type is identical to the <Who-Provides?> message but with the
  150.     extra requirement that a reply must always be returned.  When a
  151.     receiving host provides none of the requested resources, it simply
  152.     returns an empty reply list.  This empty reply list allows the
  153.     querying host to immediately detect that the confirming host
  154.     provides none of the named resources without having to timeout after
  155.     repeatedly retransmitting the request.
  156.  
  157. The <Who-Provides?> request message is most typically used when
  158. broadcasting requests to an entire IP network.  The <Do-You-Provide?>
  159. request message, on the other hand, is most typically used when
  160. confirming that a particular host does or does not provide one or more
  161. specific resources.  It may not be broadcast (since such a request would
  162. flood the querying host with reply messages from all hosts on the
  163. network).
  164.  
  165. In addition to the two basic types of request messages, an additional
  166. two variant types of request messages may also be transmitted by a
  167. querying host.  These message types provide a "third-party" resource
  168. location capability.  They differ from the basic message types by
  169.  
  170.  
  171. Accetta                                                         [Page 3]
  172.  
  173. RFC 887                                                    December 1983
  174. Resource Location Protocol
  175.  
  176. providing space for an additional qualifier with each listed resource to
  177. identify "third-party" hosts which the confirming host believes may
  178. provide the resource.  As before, the first type requires any host
  179. receiving the request message to return a reply message only if it knows
  180. of some host which provides at least one of the resources named in the
  181. request list.  The second type requires any host receiving the message
  182. to always return a reply message even if it knows of no hosts which
  183. provide any of the resources named in the request list.
  184.  
  185. These two remaining types of request messages are:
  186.  
  187. <Who-Anywhere-Provides?>
  188.     This message parallels the <Who-Provides?> message with the
  189.     "third-party" variant described above.  The confirming host is
  190.     required to return at least its own IP address (if it provides the
  191.     named resource) as well as the IP addresses of any other hosts it
  192.     believes may provide the named resource.  The confirming host
  193.     though, may never return an IP address for a resource which is the
  194.     same as an IP address listed with the resource name in the request
  195.     message.  In this case it must treat the resource as if it was
  196.     unsupported at that IP address and omit it from any reply list.
  197.  
  198. <Does-Anyone-Provide?>
  199.     This message parallels the <Do-You-Provide?> message again with the
  200.     "third-party" variant described above.  As before, the confirming
  201.     host is required to return its own IP address as well as the IP
  202.     addresses of any other hosts it believes may provide the named
  203.     resource and is prohibited from returning the same IP address in the
  204.     reply resource specifier as was listed in the request resource
  205.     specifier.  As in the <Do-You-Provide?> case and for the same
  206.     reason, this message also may not be broadcast.
  207.  
  208. These variant request messages permit "smart" hosts to supply resource
  209. location information for networks without broadcast capability (provided
  210. that all hosts on the network always "know" the address of one or more
  211. such "smart" hosts).  They also permit resource location information for
  212. services which are not provided anywhere on a directly connected network
  213. to be provided by "smart" gateways which have perhaps queried other
  214. networks to which they are attached or have somehow otherwise acquired
  215. the information.
  216.  
  217. The restriction against returning the same IP address in a reply as was
  218. specified in the request provides a primitive mechanism for excluding
  219. certain known addresses from consideration in a reply (see section 5,
  220. example 3).  It may also be used to override the receiving host's
  221. preference for its own IP address in "third-party" replies when this is
  222. required.
  223.  
  224.  
  225.  
  226.  
  227.  
  228. Accetta                                                         [Page 4]
  229.  
  230. RFC 887                                                    December 1983
  231. Resource Location Protocol
  232.  
  233. 3.2. Reply Messages
  234.  
  235. Each of the types of request messages has an associated type of reply
  236. message.  The basic reply message type is returned in response to both
  237. <Who-Provides?> and <Do-You-Provide?> request messages and supplies
  238. information about the resources provided by the confirming host.  The
  239. other reply message type is the "third-party" variant returned in
  240. response to both <Who-Anywhere-Provides?> and <Does-Anyone-Provide?>
  241. request messages and supplies information about resources provided by
  242. hosts known to the confirming host.
  243.  
  244. These two types of reply messages are:
  245.  
  246. <I-Provide>
  247.     This reply message contains a list of exactly those resources from
  248.     the request list which the confirming host provides.  These
  249.     resources must occur in the reply list in precisely the same order
  250.     as they were listed in the request message.
  251.  
  252. <They-Provide>
  253.     This reply message similarly contains a list of exactly those
  254.     resources from the request list (appropriately qualified with IP
  255.     addresses) which the confirming host provides or believes another
  256.     host provides.  These resources again must occur in the reply list
  257.     in precisely the same order as they were listed in the request
  258.     message.
  259.  
  260. Neither type of reply message may be broadcast.
  261.  
  262. A querying host which receives a <They-Provide> reply message from a
  263. confirming host on behalf of a third host is not required to
  264. unquestioningly rely on the indirectly provided information.  This
  265. information should usually be regarded simply as a hint.  In most cases,
  266. the querying host should transmit a specific <Do-You-Provide?> request
  267. to the third host and confirm that the resource is indeed provided at
  268. that IP address before proceeding.
  269.  
  270. 4. Message Formats
  271.  
  272. RLP messages are encapsulated in UDP packets to take advantage of the
  273. multiplexing capability provided by the UDP source and destination ports
  274. and the extra reliability provided by the UDP checksum.  Request
  275. messages are sent from a convenient source port on the querying host to
  276. the assigned RLP destination port of a receiving host.  Reply messages
  277. are returned from the assigned RLP source port of the confirming host to
  278. the appropriate destination port of the querying host as determined by
  279. the source port in the request message.
  280.  
  281. The format of the various RLP messages is described in the following
  282. diagrams.  All numeric quantities which occupy more than one octet are
  283.  
  284.  
  285. Accetta                                                         [Page 5]
  286.  
  287. RFC 887                                                    December 1983
  288. Resource Location Protocol
  289.  
  290. stored in the messages from the high order octet to the low order octet
  291. as per the usual Internet protocol standard.  All packet diagrams
  292. indicate the octets of the message from left to right and then top to
  293. bottom as they occur in the data portion of the encapsulating UDP
  294. packet.
  295.  
  296. Each RLP packet has the general format
  297.  
  298.                  +--------+--------+--------+--------+
  299.                  |        |        |                 |
  300.                  |  Type  | Flags  |   Message-ID    |
  301.                  |        |        |                 |
  302.                  +--------+--------+--------+--------+
  303.                  |                                   -
  304.                  |           Resource-List           -
  305.                  |                                   -
  306.                  +--------+--------+--------+---\\---+
  307.                  -                                   +
  308.                  -           Resource-List           |
  309.                  -                                   |
  310.                  +--------+--------+--------+---\\---+
  311.  
  312. where
  313.  
  314. <Type>
  315.     is a single octet which identifies the message type.  The currently
  316.     defined types are:
  317.  
  318.     0     <Who-Provides?>
  319.     1     <Do-You-Provide?>
  320.     2     <Who-Anywhere-Provides?>
  321.     3     <Does-Anyone-Provide?>
  322.     4     <I-Provide>
  323.     5     <They-Provide>
  324.     6-255 Reserved.
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342. Accetta                                                         [Page 6]
  343.  
  344. RFC 887                                                    December 1983
  345. Resource Location Protocol
  346.  
  347. <Flags>
  348.     is a single octet specifying possible modifications to the standard
  349.     interpretation of <Type>.  Bits in this field are numbered from left
  350.     to right (from most significant to least significant) beginning with
  351.     bit 1.  The currently defined flag bits are:
  352.  
  353.     Bit 1    <Local-Only>.  Requires that any reply message generated in
  354.              response to a request message with this flag bit set may
  355.              only name IP addresses which are on the same IP network as
  356.              the sender of the request message.  This flag also requires
  357.              that multi-homed hosts answering broadcast <Who-Provides?>
  358.              requests use the appropriate local network IP source
  359.              address in the returned reply.  This bit must be zero in
  360.              reply messages.
  361.     Bits 2-8 Reserved.  Must be zero.
  362.  
  363. <Message-ID>
  364.     is a two octet (16-bit) value which identifies the request message.
  365.     It is used simply to aid in matching requests with replies.  The
  366.     sending host should initialize this field to some convenient value
  367.     when constructing a request message.  The receiving host must return
  368.     this same value in the <Message-ID> field of any reply message
  369.     generated in response to that request.
  370.  
  371. <Resource-List>
  372.     is the list of resources being queried or for which location
  373.     information is being supplied.  This list is a sequence of octets
  374.     beginning at the octet following the <Message-ID> and extending
  375.     through the end of the UDP packet.  The format of this field is
  376.     explained more fully in the following section.  The size of this
  377.     list is implicitly specified by the length of the encapsulating UDP
  378.     datagram.
  379.  
  380.  
  381.  
  382. 4.1. Resource Lists
  383.  
  384. A <Resource-List> consists of zero or more resource specifiers.  Each
  385. resource specifier is simply a sequence of octets.  All resource
  386. specifiers have a common resource name initial format
  387.  
  388.                  +--------+--------+--------+---\\---+
  389.                  |        |        |                 |
  390.                  |Protocol|IDLength|   Resource-ID   |
  391.                  |        |        |                 |
  392.                  +--------+--------+--------+---\\---+
  393.  
  394. where
  395.  
  396.  
  397.  
  398.  
  399. Accetta                                                         [Page 7]
  400.  
  401. RFC 887                                                    December 1983
  402. Resource Location Protocol
  403.  
  404. <Protocol>
  405.     is the protocol number assigned to the lowest level Internet
  406.     protocol utilized for accessing the resource.
  407.  
  408. <IDLength>
  409.     is the length of the resource identifier associated with this
  410.     <Protocol>.  This length may be a fixed or variable value depending
  411.     on the particular resource.  It is included so that specifiers which
  412.     refer to resources which a host may not provide can be skipped over
  413.     without needing to know the specific structure of the particular
  414.     resource identifier.  If the <Protocol> has no associated natural
  415.     identifier, this length is 0.
  416.  
  417. <Resource-ID>
  418.     is the qualifying identifier used to further refine the resource
  419.     being queried.  If the <IDLength> field was 0, then this field is
  420.     empty and occupies no space in the resource specifier.
  421.  
  422. In addition, resource specifiers in all <Who-Anywhere-Provides?>,
  423. <Does-Anyone-Provide?> and <They-Provide> messages also contain an
  424. additional qualifier following the <Protocol-ID>.  This qualifier has
  425. the format
  426.  
  427.              +--------+--------+--------+--------+---//---+
  428.              |        |                                   |
  429.              |IPLength|          IP-Address-List          |
  430.              |        |                                   |
  431.              +--------+--------+--------+--------+---//---+
  432.  
  433. where
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456. Accetta                                                         [Page 8]
  457.  
  458. RFC 887                                                    December 1983
  459. Resource Location Protocol
  460.  
  461. <IPLength>
  462.     is the number of IP addresses containing in the following
  463.     <IP-Address-List> (the <IP-Address-List> field thus occupies the
  464.     last 4*<IPLength> octets in its resource specifier).  In request
  465.     messages, this is the maximum number of qualifying addresses which
  466.     may be included in the corresponding reply resource specifier.
  467.     Although not particularly useful, it may be 0 and in that case
  468.     provides no space for qualifying the resource name with IP addresses
  469.     in the returned specifier.  In reply messages, this is the number of
  470.     qualifying addresses known to provide the resource.  It may not
  471.     exceed the number specified in the corresponding request specifier.
  472.     This field may not be 0 in a reply message unless it was supplied as
  473.     0 in the request message and the confirming host would have returned
  474.     one or more IP addresses had any space been provided.
  475.  
  476. <IP-Address-List>
  477.     is a list of four-octet IP addresses used to qualify the resource
  478.     specifier with respect to those particular addresses.  In reply
  479.     messages, these are the IP addresses of the confirming host (when
  480.     appropriate) and the addresses of any other hosts known to provide
  481.     that resource (subject to the list length limitations).  In request
  482.     messages, these are the IP addresses of hosts for which resource
  483.     information may not be returned.  In such messages, these addresses
  484.     should normally be initialized to some "harmless" value (such as the
  485.     address of the querying host) unless it is intended to specifically
  486.     exclude the supplied addresses from consideration in any reply
  487.     messages.
  488.  
  489. The receiving host determines if it provides any of the resources named
  490. in the request list by successively decomposing each resource name.  The
  491. first level of decomposition is the Internet protocol number which can
  492. presumably be looked up in a table to determine if that protocol is
  493. supported on the host.  Subsequent decompositions are based on previous
  494. components until one of three events occur:
  495.  
  496.    1. the current component identifies some aspect of the previous
  497.       components which the host does not support,
  498.  
  499.    2. the resource name from the request list is exhausted, or
  500.  
  501.    3. the resource name from the request list is not exhausted but
  502.       the host does not expect any further components in the name
  503.       given the previous components
  504.  
  505. In case 1, the receiving host has determined that it does not provide
  506. the named resource.  The resource specifier may not be included in any
  507. reply message returned.
  508.  
  509. In case 2, the receiving host has determined that it does indeed provide
  510. the named resource (note: this may occur even if the receiving host
  511.  
  512.  
  513. Accetta                                                         [Page 9]
  514.  
  515. RFC 887                                                    December 1983
  516. Resource Location Protocol
  517.  
  518. would have expected the resource name to contain more components than
  519. were actually present).  The resource specifier must be included (modulo
  520. IP address prohibitions) in any reply message returned.
  521.  
  522. In case 3, the receiving host has determined that it does not completely
  523. provide the named resource since name components remain which it does
  524. not understand (this might occur with specializations of or extensions
  525. to a known protocol which are not universally recognized).  The resource
  526. specifier may not be included in any reply message returned.
  527.  
  528. 5. Sample Usage
  529.  
  530. The following scenarios illustrate some typical uses of RLP.  In all
  531. cases the indicated messages are encapsulated in a UDP datagram with the
  532. appropriate source and destination port numbers, message length, and
  533. checksum.  This datagram is further encapsulated in an IP datagram with
  534. the appropriate source address of the sending host and destination
  535. address (either broadcast or individual) for the receiving host.
  536.  
  537. All numeric protocol examples are as specified in the appropriate
  538. protocol description documents listed in the references.
  539.  
  540.  1. Suppose a freshly rebooted host H wishes to find some gateway
  541.     on its directly connected network to which it can send its
  542.     first external packet.  It then broadcasts the request
  543.  
  544.         <Who-Provides?> <Flags>=<Local-Only> <Message-ID>=12345
  545.                     <Resource-List>={[GGP], [EGP]}
  546.  
  547.     encoded as the 8 octet message
  548.  
  549.            +-----+-----+-----+-----+-----+-----+-----+-----+
  550.            |  0  | 128 |   12345   |  3  |  0  |  8  |  0  |
  551.            +-----+-----+-----+-----+-----+-----+-----+-----+
  552.  
  553.     on its local network.
  554.  
  555.      - Gateway G1 (which understands EGP) receives the request and
  556.        returns the reply
  557.  
  558.                <I-Provide> <Flags>=none <Message-ID>=12345
  559.                          <Resource-List>={[EGP]}
  560.  
  561.        encoded as the 6 octet message
  562.  
  563.                   +-----+-----+-----+-----+-----+-----+
  564.                   |  4  |  0  |   12345   |  8  |  0  |
  565.                   +-----+-----+-----+-----+-----+-----+
  566.  
  567.        to host H which then remembers that gateway G1 may be used
  568.  
  569.  
  570. Accetta                                                        [Page 10]
  571.  
  572. RFC 887                                                    December 1983
  573. Resource Location Protocol
  574.  
  575.        to route traffic to the rest of the Internet.
  576.  
  577.      -  At the same time, gateway G2 (which understands both GGP
  578.        and EGP) might also receive the request and return the reply
  579.  
  580.                <I-Provide> <Flags>=none <Message-ID>=12345
  581.                       <Resource-List>={[GGP], [EGP]}
  582.  
  583.        encoded as the 8 octet message
  584.  
  585.             +-----+-----+-----+-----+-----+-----+-----+-----+
  586.             |  4  |  0  |   12345   |  3  |  0  |  8  |  0  |
  587.             +-----+-----+-----+-----+-----+-----+-----+-----+
  588.  
  589.        to host H which might then also add gateway G2 to its list
  590.        if it chooses.
  591.  
  592.  2. Assume instead that host H is a stand-alone system which has
  593.     just encountered some fatal software error and wishes to locate
  594.     a crash dump server to save its state before reloading.
  595.     Suppose that the crash dump protocol on the host's local
  596.     network is implemented using the Trivial File Transfer Protocol
  597.     (TFTP) [8].  Furthermore, suppose that the special file name
  598.     "CRASH-DUMP" is used to indicate crash dump processing (e.g.
  599.     the server might locally generate a unique file name to hold
  600.     each dump that it receives from a host).  Then host H might
  601.     broadcast the request
  602.  
  603.             <Who-Provides?> <Flags>=none <Message-ID>=54321
  604.            <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}
  605.  
  606.     encoded as the 21 octet message
  607.  
  608.            +-----+-----+-----+-----+-----+-----+-----+-----+
  609.            |  0  |  0  |   54321   |  17 |  15 |     69    |
  610.            +-----+-----+-----+-----+-----+-----+-----+-----+
  611.            |     2     | 'C'   'R'   'A'   'S'   'H'   '-' |
  612.            +-----+-----+-----+-----+-----+-----+-----+-----+
  613.            | 'D'   'U'   'M'   'P'    0  |                  
  614.            +-----+-----+-----+-----+-----+                  
  615.  
  616.     to its local network (note that the file name component is
  617.     explicitly terminated by a null so as not to exclude future
  618.     further specialization of the crash dump protocol).
  619.  
  620.      - Host C (which supports this specialization of the TFTP
  621.        protocol) receives the request and returns the reply
  622.  
  623.                <I-Provide> <Flags>=none <Message-ID>=54321
  624.              <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}
  625.  
  626.  
  627. Accetta                                                        [Page 11]
  628.  
  629. RFC 887                                                    December 1983
  630. Resource Location Protocol
  631.  
  632.        encoded as the 21 octet message
  633.  
  634.  
  635.             +-----+-----+-----+-----+-----+-----+-----+-----+
  636.             |  4  |  0  |   54321   |  17 |  15 |     69    |
  637.             +-----+-----+-----+-----+-----+-----+-----+-----+
  638.             |     2     | 'C'   'R'   'A'   'S'   'H'   '-' |
  639.             +-----+-----+-----+-----+-----+-----+-----+-----+
  640.             | 'D'   'U'   'M'   'P'    0  |                  
  641.             +-----+-----+-----+-----+-----+                  
  642.  
  643.        to host H which may then proceed to send its crash dump to
  644.        host C and reload.
  645.  
  646.      - Host D (which provides TFTP service but not the crash dump
  647.        specialization), however, might receive the request and
  648.        determine that it provides no support for the resource
  649.        (since the resource name contains components following the
  650.        UDP port number which it does not understand).  It would
  651.        therefore return no reply to host H. 
  652.  
  653.  3. Finally, suppose host M wishes to locate some domain name
  654.     translation server (either UDP or TCP based) anywhere on the
  655.     Internet.  Furthermore, suppose that host M is on a IP network
  656.     which does not provide broadcast address capabilities and that
  657.     host R is a "known" resource location server for that network.
  658.  
  659.     First, since host M prefers to find a domain name server on its
  660.     own locally connected network if possible, it sends the request
  661.  
  662.               <Does-Anyone-Provide?> <Flags>=<Local-Only>
  663.                   <Message-ID>=12321 <Resource-List>=
  664.                 {[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},
  665.                  [UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}
  666.  
  667.     encoded as the 22 octet message
  668.  
  669.         +-----+-----+-----+-----+                              
  670.         |  3  | 128 |   12321   |                              
  671.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  672.         |  6  |  2  |     53    |  1  |           M           |
  673.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  674.         |  17 |  2  |     53    |  1  |           M           |
  675.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  676.  
  677.     to host R. 
  678.  
  679.     Host R receives the request and consults its tables for any
  680.     hosts known to support either variety of domain name service.
  681.     It finds entries indicating that both hosts S and T provide UDP
  682.  
  683.  
  684. Accetta                                                        [Page 12]
  685.  
  686. RFC 887                                                    December 1983
  687. Resource Location Protocol
  688.  
  689.     based domain name service but that neither host is on the same
  690.     IP network as host H. It must then send the negative
  691.     confirmation reply
  692.  
  693.             <They-Provide> <Flags>=none <Message-ID>=12321
  694.                           <Resource-List>={}
  695.  
  696.     encoded as the 4 octet message
  697.  
  698.                        +-----+-----+-----+-----+
  699.                        |  5  |  0  |   12321   |
  700.                        +-----+-----+-----+-----+
  701.  
  702.     back to host M. 
  703.  
  704.     Host M, receiving this reply, might now abandon any hope of
  705.     finding a server on its own network, reformat its request to
  706.     permit any host address, and resend
  707.  
  708.         <Does-Anyone-Provide?> <Flags>=none <Message-ID>=12322
  709.                            <Resource-List>=
  710.                 {[TCP, <DOMAIN-NAME-SERVER-PORT>] {M},
  711.                  [UDP, <DOMAIN-NAME-SERVER-PORT>] {M}}
  712.  
  713.     encoded as the 22 octet message
  714.  
  715.         +-----+-----+-----+-----+                              
  716.         |  3  |  0  |   12322   |                              
  717.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  718.         |  6  |  2  |     53    |  1  |           M           |
  719.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  720.         |  17 |  2  |     53    |  1  |           M           |
  721.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  722.  
  723.     again to host R. 
  724.  
  725.     Host R receives this new request and is no longer constrained
  726.     to return only local addresses.  However, since only space for
  727.     a single qualifying IP address was provided in each request
  728.     resource specifier, it may not immediately return both
  729.     addresses.  Instead, it is forced to return only the first
  730.     address and replies
  731.  
  732.             <They-Provide> <Flags>=none <Message-ID>=12322
  733.         <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}
  734.  
  735.     encoded as the 13 octet message
  736.  
  737.  
  738.  
  739.  
  740.  
  741. Accetta                                                        [Page 13]
  742.  
  743. RFC 887                                                    December 1983
  744. Resource Location Protocol
  745.  
  746.            +-----+-----+-----+-----+-----+-----+-----+-----+
  747.            |  5  |  0  |   12322   |  17 |  2  |     53    |
  748.            +-----+-----+-----+-----+-----+-----+-----+-----+
  749.            |  1  |           S           |                  
  750.            +-----+-----+-----+-----+-----+                  
  751.  
  752.     to Host M. 
  753.  
  754.     Host M receives the reply and (being the suspicious sort)
  755.     decides to confirm it with host S. It then sends
  756.  
  757.            <Do-You-Provide?> <Flags>=none <Message-ID>=12323
  758.           <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}
  759.  
  760.     encoded as the 8 octet message
  761.  
  762.            +-----+-----+-----+-----+-----+-----+-----+-----+
  763.            |  1  |  0  |   12323   |  17 |  2  |     53    |
  764.            +-----+-----+-----+-----+-----+-----+-----+-----+
  765.  
  766.     to host S and receives back from host S the reply
  767.  
  768.               <I-Provide> <Flags>=none <Message-ID>=12323
  769.                           <Resource-List>={}
  770.  
  771.     encoded as the 4 octet message
  772.  
  773.                        +-----+-----+-----+-----+
  774.                        |  4  |  0  |   12323   |
  775.                        +-----+-----+-----+-----+
  776.  
  777.     denying any support for UDP based domain name service.
  778.  
  779.     In desperation host M again queries host R, this time excluding
  780.     host S from consideration, and sends the request
  781.  
  782.         <Does-Anyone-Provide?> <Flags>=none <Message-ID>=12324
  783.                            <Resource-List>=
  784.                 {[TCP, <DOMAIN-NAME-SERVER-PORT>] {S},
  785.                  [UDP, <DOMAIN-NAME-SERVER-PORT>] {S}}
  786.  
  787.     encoded as the 22 octet message
  788.  
  789.         +-----+-----+-----+-----+                              
  790.         |  3  |  0  |   12324   |                              
  791.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  792.         |  6  |  2  |     53    |  1  |           S           |
  793.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  794.         |  17 |  2  |     53    |  1  |           S           |
  795.         +-----+-----+-----+-----+-----+-----+-----+-----+-----+
  796.  
  797.  
  798. Accetta                                                        [Page 14]
  799.  
  800. RFC 887                                                    December 1983
  801. Resource Location Protocol
  802.  
  803.     and this time receives the reply
  804.  
  805.  
  806.             <They-Provide> <Flags>=none <Message-ID>=12324
  807.         <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>] {T}}
  808.  
  809.     encoded as the 13 octet message
  810.  
  811.            +-----+-----+-----+-----+-----+-----+-----+-----+
  812.            |  5  |  0  |   12324   | 17  |  2  |     53    |
  813.            +-----+-----+-----+-----+-----+-----+-----+-----+
  814.            |  1  |           T           |                  
  815.            +-----+-----+-----+-----+-----+                  
  816.  
  817.     from host R which of course host M again insists on confirming
  818.     by sending the request
  819.  
  820.            <Do-You-Provide?> <Flags>=none <Message-ID>=12325
  821.                            <Resource-List>=
  822.                   {[UDP, <DOMAIN-NAME-SERVER-PORT>]}
  823.  
  824.     encoded as the 8 octet message
  825.  
  826.            +-----+-----+-----+-----+-----+-----+-----+-----+
  827.            |  1  |  0  |   12325   |  17 |  2  |     53    |
  828.            +-----+-----+-----+-----+-----+-----+-----+-----+
  829.  
  830.     to host T and finally receives confirmation from host T with
  831.     the reply
  832.  
  833.               <I-Provide> <Flags>=none <Message-ID>=12325
  834.           <Resource-List>={[UDP, <DOMAIN-NAME-SERVER-PORT>]}
  835.  
  836.     encoded as the 8 octet message
  837.  
  838.            +-----+-----+-----+-----+-----+-----+-----+-----+
  839.            |  4  |  0  |   12325   |  17 |  2  |     53    |
  840.            +-----+-----+-----+-----+-----+-----+-----+-----+
  841.  
  842.     that it indeed provides domain name translation service at UDP
  843.     port 53.
  844.  
  845. A. Assigned Numbers
  846.  
  847. The "well-known" UDP port number for the Resource Location Protocol is
  848. 39 (47 octal).
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855. Accetta                                                        [Page 15]
  856.  
  857. RFC 887                                                    December 1983
  858. Resource Location Protocol
  859.  
  860.                                REFERENCES
  861.  
  862. [1]   Postel, J.
  863.       User Datagram Protocol.
  864.       RFC 768, USC/Information Sciences Institute, August, 1980.
  865.  
  866. [2]   Postel, J.
  867.       File Transfer Protocol.
  868.       RFC 765, USC/Information Sciences Institute, June, 1980.
  869.  
  870. [3]   Postel, J.
  871.       Internet Protocol - DARPA Internet Program Protocol Specification.
  872.       RFC 791, USC/Information Sciences Institute, September, 1981.
  873.  
  874. [4]   Postel, J.
  875.       Transmission Control Protocol- DARPA Internet Program Protocol
  876.          Specification.
  877.       RFC 793, USC/Information Sciences Institute, September, 1981.
  878.  
  879. [5]   Postel, J.
  880.       Internet Control Message Protocol - DARPA Internet Program
  881.          Protocol Specification.
  882.       RFC 792, USC/Information Sciences Institute, September, 1981.
  883.  
  884. [6]   Reynolds, J., and J. Postel.
  885.       Assigned Numbers.
  886.       RFC 870, USC/Information Sciences Institute, October, 1983.
  887.  
  888. [7]   Gurwitz, R., and R. Hinden.
  889.       IP - Local Area Network Addressing Issues.
  890.       IEN 212, Bolt Beranek and Newman, September, 1982.
  891.  
  892. [8]   Sollins, K.
  893.       The TFTP Protocol (revision 2).
  894.       RFC 783, MIT/Laboratory for Computer Science, June, 1981.
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912. Accetta                                                        [Page 16]
  913.  
  914.